Update `channel_reestablish` for splicing #3886

jkczyz · 2025-06-24T00:12:11Z

The splicing spec extends the channel_reestablish message with two more TLVs indicating which funding txid the sender has sent/received either explicitly via splice_locked or implicitly via channel_ready. This allows peers to detect if a splice_locked was lost during disconnection and must be retransmitted.

To this end, the spec updates the channel_reestablish logic to support splicing.

ldk-reviews-bot · 2025-06-24T00:12:14Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-reviews-bot · 2025-06-26T00:13:17Z

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz · 2025-06-27T17:12:50Z

@wpaulino Ready for review now.

codecov · 2025-06-27T17:13:47Z

Codecov Report

❌ Patch coverage is 91.30435% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.72%. Comparing base (96f9242) to head (5feb4fd).
⚠️ Report is 81 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	76.00%	12 Missing ⚠️
lightning/src/ln/channel.rs	96.59%	5 Missing ⚠️
lightning/src/ln/channelmanager.rs	87.50%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3886      +/-   ##
==========================================
+ Coverage   88.61%   88.72%   +0.10%     
==========================================
  Files         174      176       +2     
  Lines      127640   128918    +1278     
  Branches   127640   128918    +1278     
==========================================
+ Hits       113113   114381    +1268     
+ Misses      12046    11942     -104     
- Partials     2481     2595     +114

Flag	Coverage Δ
fuzzing	`21.91% <25.74%> (?)`
tests	`88.55% <91.30%> (-0.07%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-06-28T00:14:12Z

🔔 2nd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-30T00:15:02Z

🔔 3rd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-07-02T00:15:46Z

🔔 4th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-07-05T00:01:02Z

🔔 5th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-07-07T00:01:48Z

🔔 6th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz · 2025-07-07T21:03:02Z

Rebased.

wpaulino

We may need to double check our incoming channel_ready handling to make sure we can handle receiving one long after channel_ready was already exchanged due to the new logic surrounding your_last_funding_locked_txid.

lightning-types/src/features.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

ldk-reviews-bot · 2025-07-07T22:48:56Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

jkczyz

We may need to double check our incoming channel_ready handling to make sure we can handle receiving one long after channel_ready was already exchanged due to the new logic surrounding your_last_funding_locked_txid.

ACK. Also need to address https://github.com/lightningdevkit/rust-lightning/pull/3736/files#r2133028859.

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

jkczyz · 2025-07-09T22:19:52Z

Also need to address https://github.com/lightningdevkit/rust-lightning/pull/3736/files#r2133028859.

Latest push adds some commits to address this.

jkczyz · 2025-07-09T22:48:02Z

We may need to double check our incoming channel_ready handling to make sure we can handle receiving one long after channel_ready was already exchanged due to the new logic surrounding your_last_funding_locked_txid.

Looks like we have some logic below. I think the catch-all case still holds? We should only receive a channel_ready if we didn't set your_last_funding_locked_txid.

rust-lightning/lightning/src/ln/channel.rs

Lines 6491 to 6519 in 42085b9

    
           	// If we reconnected before sending our `channel_ready` they may still resend theirs. 
        
           	ChannelState::ChannelReady(_) => check_reconnection = true, 
        
           	_ => return Err(ChannelError::close("Peer sent a channel_ready at a strange time".to_owned())), 
        
           } 
        
           if check_reconnection { 
        
           	// They probably disconnected/reconnected and re-sent the channel_ready, which is 
        
           	// required, or they're sending a fresh SCID alias. 
        
           	let expected_point = 
        
           		if self.context.cur_counterparty_commitment_transaction_number == INITIAL_COMMITMENT_NUMBER - 1 { 
        
           			// If they haven't ever sent an updated point, the point they send should match 
        
           			// the current one. 
        
           			self.context.counterparty_cur_commitment_point 
        
           		} else if self.context.cur_counterparty_commitment_transaction_number == INITIAL_COMMITMENT_NUMBER - 2 { 
        
           			// If we've advanced the commitment number once, the second commitment point is 
        
           			// at `counterparty_prev_commitment_point`, which is not yet revoked. 
        
           			debug_assert!(self.context.counterparty_prev_commitment_point.is_some()); 
        
           			self.context.counterparty_prev_commitment_point 
        
           		} else { 
        
           			// If they have sent updated points, channel_ready is always supposed to match 
        
           			// their "first" point, which we re-derive here. 
        
           			Some(PublicKey::from_secret_key(&self.context.secp_ctx, &SecretKey::from_slice( 
        
           					&self.context.commitment_secrets.get_secret(INITIAL_COMMITMENT_NUMBER - 1).expect("We should have all prev secrets available") 
        
           				).expect("We already advanced, so previous secret keys should have been validated already"))) 
        
           		}; 
        
           	if expected_point != Some(msg.next_per_commitment_point) { 
        
           		return Err(ChannelError::close("Peer sent a reconnect channel_ready with a different point".to_owned())); 
        
           	} 
        
           	return Ok(None); 
        
           }

While splicing is not yet fully supported, checking if the feature has been negotiated is needed for changes to the channel_reestablish logic.

The splicing spec extends the channel_reestablish message with two more TLVs indicating which funding txid the sender has sent/received either explicitly via splice_locked or implicitly via channel_ready. This allows peers to detect if a splice_locked was lost during disconnection and must be retransmitted. This commit updates channel_reestablish with the TLVs. Subsequent commits will implement the spec requirements.

The previous commit extended the channel_reestablish message with your_last_funding_locked_txid and my_current_funding_locked_txid for use as described there. This commit sets those fields to the funding txid most recently sent/received accordingly.

jkczyz · 2025-08-19T20:37:37Z

Feel free to squash, simplify, and rebase IMO

Done.

TheBlueMatt · 2025-08-20T13:29:57Z

lightning/src/ln/channel.rs

@@ -1215,6 +1215,7 @@ pub(super) struct ReestablishResponses {
 	pub shutdown_msg: Option<msgs::Shutdown>,
 	pub tx_signatures: Option<msgs::TxSignatures>,
 	pub tx_abort: Option<msgs::TxAbort>,
+	pub implicit_splice_locked: Option<msgs::SpliceLocked>,


Bleh, let's please note rely on ChannelManager to pipe channel.rs logic around in a loop. We need to be exposing Channel-internal to ChannelManager less, not more.

May just need to rename this as there is some update logic that needs to be executed in ChannelManager::internal_splice_locked. Will re-visit to see if there's a better alternative.

TheBlueMatt · 2025-08-20T14:14:41Z

lightning/src/ln/channel.rs

-							} else {
-								session.holder_tx_signatures().clone()
-							}
+					if !session.has_received_commitment_signed() {


Isn't this unreachable per the comment in maybe_get_next_funding_txid - "Since we have a signing_session, this implies we've sent an initial commitment_signed"? Or do we switch to interactive signing once we send our CS, before our peer sends their CS (and should we?).

Or do we switch to interactive signing once we send our CS, before our peer sends their CS (and should we?).

Based on offline discussion with @wpaulino this statement is true.

TheBlueMatt · 2025-08-20T14:19:07Z

lightning/src/ln/channel.rs

+					//   -  MUST retransmit its `commitment_signed` for that funding transaction.
+					if msg.next_local_commitment_number == next_counterparty_commitment_number {
+						// `next_counterparty_commitment_number` is guaranteed to always be the
+						// commitment number of the `commitment_signed` message we sent for this


This seems wrong re: #4014.

@wpaulino said he will take a look when reviewing. Seems we'll need to follow-up in the spec meeting to potentially add a retransmit flag to retransmit commitment_signed.

Could either of you comment on the spec PR as to what you had in mind with retransmit_flags? Might be worth having t-bast think on it before the spec meeting.

lightning/bolts#1160 (comment)

Updated to next_funding_txid to be next_funding with a txid and retransmit_flags as discussed on the spec.

TheBlueMatt · 2025-08-20T14:20:47Z

lightning/src/ln/channel.rs

+					// - if it has already received `tx_signatures` for that funding transaction:
+					//   - MUST send its `tx_signatures` for that funding transaction.
+					if (session.has_received_commitment_signed() && session.holder_sends_tx_signatures_first())
+						|| self.context.channel_state.is_their_tx_signatures_sent()


Don't we need to check has_received_commitment_signed() even in the case where they already sent their tx signatures? Or can the state machine not advance in that case?

Based on offline discussion self.context.channel_state.is_their_tx_signatures_sent() implies session.has_received_commitment_signed().

TheBlueMatt · 2025-08-20T14:30:42Z

lightning/src/ln/channel.rs

-					// on reestablish and tell our peer to just forget about it.
-					// Our peer is doing something strange, but it doesn't warrant closing the channel.
-					(None, None, Some(msgs::TxAbort {
+					// The `next_funding_txid` does not match the latest interactive funding


This is the else block for where maybe_get_next_funding_txid returned None, not where the txid doesn't match, so the comment is confusing. But I'm also a bit less clear on the second case of maybe_get_next_funding_txid - if we have an interactive signing session, but they did send their tx signatures (and we received them), we'll end up here, but it seems its much too late to TxAbort.

From offline discussion we'll drop the else block and use of maybe_get_next_funding_txid in the if block. Instead, we'll get the latter from the signing session.

TheBlueMatt · 2025-08-20T14:32:18Z

lightning/src/ln/channel.rs

 			})
 		} else if msg.next_local_commitment_number == next_counterparty_commitment_number - 1 {
+			// We've made an update so we must have exchanged `tx_signatures`, implying that


This might indicate we're sending our CS for the interactive signing session, right?

Related to #3886 (comment), so will depend on how that is resolved.

The proposed spec change did not include a flag for re-transmitting tx_signatures, so kept this as is for now.

I think it's because the next_funding TLV being set implies that. Now that next_counterparty_commitment_number is no longer affected by splicing, we shouldn't be re-transmitting a tx_signatures when they're behind by one state.

Not sure if you missed this, but this comment needs to change because it shouldn't be possible to retransmit tx_signatures in this case (and we should assert it's None).

jkczyz

Discussed recent review comments offline. Left some notes about what was decided. @TheBlueMatt @wpaulino Feel free to expand on anything there that isn't clear. I'll address anything that can be resolved and not blocked on discussion at the spec meeting.

jkczyz · 2025-08-20T18:54:24Z

lightning/src/ln/channel.rs

-							} else {
-								session.holder_tx_signatures().clone()
-							}
+					if !session.has_received_commitment_signed() {


Or do we switch to interactive signing once we send our CS, before our peer sends their CS (and should we?).

Based on offline discussion with @wpaulino this statement is true.

jkczyz · 2025-08-20T18:56:58Z

lightning/src/ln/channel.rs

+					//   -  MUST retransmit its `commitment_signed` for that funding transaction.
+					if msg.next_local_commitment_number == next_counterparty_commitment_number {
+						// `next_counterparty_commitment_number` is guaranteed to always be the
+						// commitment number of the `commitment_signed` message we sent for this


@wpaulino said he will take a look when reviewing. Seems we'll need to follow-up in the spec meeting to potentially add a retransmit flag to retransmit commitment_signed.

jkczyz · 2025-08-20T19:06:45Z

lightning/src/ln/channel.rs

+					// - if it has already received `tx_signatures` for that funding transaction:
+					//   - MUST send its `tx_signatures` for that funding transaction.
+					if (session.has_received_commitment_signed() && session.holder_sends_tx_signatures_first())
+						|| self.context.channel_state.is_their_tx_signatures_sent()


Based on offline discussion self.context.channel_state.is_their_tx_signatures_sent() implies session.has_received_commitment_signed().

jkczyz · 2025-08-20T19:22:25Z

lightning/src/ln/channel.rs

-					// on reestablish and tell our peer to just forget about it.
-					// Our peer is doing something strange, but it doesn't warrant closing the channel.
-					(None, None, Some(msgs::TxAbort {
+					// The `next_funding_txid` does not match the latest interactive funding


From offline discussion we'll drop the else block and use of maybe_get_next_funding_txid in the if block. Instead, we'll get the latter from the signing session.

jkczyz · 2025-08-20T19:22:51Z

lightning/src/ln/channel.rs

 			})
 		} else if msg.next_local_commitment_number == next_counterparty_commitment_number - 1 {
+			// We've made an update so we must have exchanged `tx_signatures`, implying that


Related to #3886 (comment), so will depend on how that is resolved.

jkczyz · 2025-08-20T19:24:55Z

lightning/src/ln/channel.rs

@@ -1215,6 +1215,7 @@ pub(super) struct ReestablishResponses {
 	pub shutdown_msg: Option<msgs::Shutdown>,
 	pub tx_signatures: Option<msgs::TxSignatures>,
 	pub tx_abort: Option<msgs::TxAbort>,
+	pub implicit_splice_locked: Option<msgs::SpliceLocked>,


May just need to rename this as there is some update logic that needs to be executed in ChannelManager::internal_splice_locked. Will re-visit to see if there's a better alternative.

ldk-reviews-bot · 2025-08-21T17:08:34Z

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-08-25T00:00:26Z

🔔 2nd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-08-27T00:01:11Z

🔔 3rd Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz · 2025-08-27T18:39:54Z

Squashed as requested offline.

jkczyz · 2025-08-27T20:26:50Z

Pushed a rustfmt change to fix CI.

wpaulino · 2025-08-27T22:35:24Z

lightning/src/ln/channel.rs

@@ -8665,9 +8665,9 @@ where
 		}

 		if msg.next_local_commitment_number >= INITIAL_COMMITMENT_NUMBER || msg.next_remote_commitment_number >= INITIAL_COMMITMENT_NUMBER ||
-			(msg.next_local_commitment_number == 0 && msg.next_funding_txid.is_none()) {
+			(msg.next_local_commitment_number == 0 && msg.next_funding.is_none()) {


This change can be dropped now that the next_local_commitment_number isn't ever decremented in the next_funding case, right?

Which change? This line is just updating the field name.

Oops, the msg.next_funding.is_none check can be dropped though since it cannot be zero anymore if next_funding is set.

wpaulino · 2025-08-27T22:39:39Z

lightning/src/ln/channel.rs

+					// `next_counterparty_commitment_number` is guaranteed to always be the
+					// commitment number of the `commitment_signed` message we sent for this
+					// funding transaction. If they set `next_funding`, then they should not have
+					// processed our `tx_signatures` yet, which implies that our state machine is
+					// still paused and no updates can happen that would increment our
+					// `next_counterparty_commitment_number`.
+					//
+					// If they did set `next_funding` even after processing our `tx_signatures`
+					// erroneously, this may end up resulting in a force close.


I think this whole comment isn't really relevant anymore

wpaulino · 2025-08-27T22:47:12Z

lightning/src/ln/channel.rs

 			})
 		} else if msg.next_local_commitment_number == next_counterparty_commitment_number - 1 {
+			// We've made an update so we must have exchanged `tx_signatures`, implying that


I think it's because the next_funding TLV being set implies that. Now that next_counterparty_commitment_number is no longer affected by splicing, we shouldn't be re-transmitting a tx_signatures when they're behind by one state.

wpaulino · 2025-08-27T22:50:55Z

lightning/src/ln/channel.rs

@@ -10492,6 +10492,25 @@ where
 		self.sign_channel_announcement(node_signer, announcement).ok()
 	}

+	fn get_next_local_commitment_number(&self) -> u64 {


Looks like this commit can be dropped now that we use the flag to signal commitment_signed needs to be retransmitted?

wpaulino · 2025-08-27T22:57:53Z

lightning/src/ln/channel.rs

+				//       - MUST set the `announcement_signatures` bit to `1` in `retransmit_flags`.
+				//     - otherwise:
+				//       - MUST set the `announcement_signatures` bit to `0` in `retransmit_flags`.
+				if self.funding.get_funding_txid() == Some(txid)


Shouldn't we still mark that the sigs need to be sent when we haven't promoted the scope yet?

Ah, right since they could have sent both splice_locked and announcement_signatures but we didn't receive either. So they would have promoted the splice but we hadn't yet. We'd infer their splice_locked on reconnect but would need to request signatures.

TheBlueMatt · 2025-08-28T01:00:45Z

lightning/src/ln/channel.rs

@@ -8744,6 +8761,7 @@ where
 				shutdown_msg, announcement_sigs,
 				tx_signatures: None,
 				tx_abort: None,
+				inferred_splice_locked: None,


Isn't it the case that we can be in AwaitingChannelReady but the peer needs a splicing signature (ie we sent ours second and they didn't receive it)? In that case we would get and return early but we really need to send a response message. I guess that's a dual-funding question not a splicing question, but might be worth leaving a TODO here or whatever.

I'm not understanding the scenario described here.

Isn't it the case that we can be in AwaitingChannelReady but the peer needs a splicing signature (ie we sent ours second and they didn't receive it)?

Sent a splice_locked second? I don't think we ever transition to AwaitingChannelReady during splicing.

In that case we would get and return early but we really need to send a response message.

Which message?

I guess that's a dual-funding question not a splicing question, but might be worth leaving a TODO here or whatever.

Hmm? Are you saying we should send a channel_ready?

TheBlueMatt · 2025-08-28T01:13:23Z

lightning/src/ln/channel.rs

+					//
+					// If they did set `next_funding` even after processing our `tx_signatures`
+					// erroneously, this may end up resulting in a force close.
+					let commitment_signed = self.context.get_initial_commitment_signed_v2(&self.funding, logger)


Doesn't this need to use the funding scope of the current splice?

Yeah, though if there isn't one it needs to be &self.funding as it indicates the signing session is for the initial funding, IIUC.

TheBlueMatt · 2025-08-28T01:19:19Z

lightning/src/ln/channel.rs

+				}
+
+				// TODO(splicing): Add comment for spec requirements
+				if next_funding.should_retransmit(msgs::NextFundingFlag::CommitmentSigned) {


In this case we may generate both a commitment_signed and a tx_signatures but the commitment_signed needs to go first. Sadly, ChannelManager::handle_channel_resumption sends tx_signatures first so that needs to swap.

TheBlueMatt · 2025-08-28T01:19:33Z

Phew that simplified this a lot.

During channel reestablishment, both commitment_signed and tx_signatures messages may be retransmitted. However, commitment_signed must come first, so re-arrange the ordering. This moves tx_abort as well to keep the interactive tx messages together.

The splicing spec updates the logic pertaining to next_funding_txid when handling a channel_reestablish message. Specifically: A receiving node: - if `next_funding_txid` is set: - if `next_funding_txid` matches the latest interactive funding transaction or the current channel funding transaction: - if `next_commitment_number` is equal to the commitment number of the `commitment_signed` message it sent for this funding transaction: - MUST retransmit its `commitment_signed` for that funding transaction. - if it has already received `commitment_signed` and it should sign first, as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): - MUST send its `tx_signatures` for that funding transaction. - if it has already received `tx_signatures` for that funding transaction: - MUST send its `tx_signatures` for that funding transaction. - if it also sets `next_funding_txid` in its own `channel_reestablish`, but the values don't match: - MUST send an `error` and fail the channel. - otherwise: - MUST send `tx_abort` to let the sending node know that they can forget this funding transaction. Note that the spec is in flux. Instead, next_funding_txid is replaced with next_funding, which contains both a txid and retransmit_flags. The latter is used instead of next_commitment_number to determine whether commitment_signed should be retransmitted. This commit updates FundedChannel::channel_reestablish accordingly. Co-authored-by: Wilmer Paulino <wilmer@wilmerpaulino.com> Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>

When a splice transaction is promoted (i.e., when splice_locked has been exchanged), announcement_signatures must be sent. However, if we try to send a channel_announcement before they are received, then the signatures will be incorrect. To avoid this, clear the counterparty's announcement_signatures upon promoting a FundingScope.

When handling a counterparties channel_reestablish, the spec dictates that a splice_locked may be implied by my_current_funding_locked. Compare that against any pending splices and handle an implicit splice_locked message when applicable.

During channel reestablishment, announcement_signatures may need to be retransmitted. The splicing spec allows doing so without retransmitting splice_locked first, which could normally trigger retransmitting announcement_signatures. Instead, my_current_funding_locked lets the sender request retransmitting it.

The previous commit allowed requesting retransmission of announcement_signatures during channel reestablishment. This commit handles such requests.

wpaulino · 2025-08-28T20:06:57Z

lightning/src/ln/channel.rs

-						}
-						(commitment_update, tx_signatures, None)
+						})
+						.or_else(|| Some(&self.funding))


I don't think there's a case where this is possible. If next_funding is set then they haven't processed our tx_signatures, so the funding cannot be locked.

Oh never mind, I see this is to handle the dual funding case.

jkczyz requested a review from wpaulino June 24, 2025 00:12

jkczyz mentioned this pull request Jun 24, 2025

Dual-funded channels and Splicing Project Tracking #1621

Open

7 tasks

jkczyz added this to Weekly Goals Jun 26, 2025

jkczyz assigned jkczyz and unassigned jkczyz Jun 26, 2025

jkczyz force-pushed the 2025-06-channel-reestablish branch 2 times, most recently from 06c0dfc to f000b76 Compare June 27, 2025 17:04

jkczyz marked this pull request as ready for review June 27, 2025 17:12

jkczyz self-assigned this Jul 3, 2025

jkczyz moved this to Goal: Merge in Weekly Goals Jul 3, 2025

jkczyz force-pushed the 2025-06-channel-reestablish branch from f000b76 to e2ea3bf Compare July 7, 2025 21:02

wpaulino reviewed Jul 7, 2025

View reviewed changes

jkczyz force-pushed the 2025-06-channel-reestablish branch from e2ea3bf to 69be701 Compare July 9, 2025 00:17

jkczyz commented Jul 9, 2025

View reviewed changes

jkczyz force-pushed the 2025-06-channel-reestablish branch 2 times, most recently from f7b9785 to b0291f4 Compare July 9, 2025 21:49

jkczyz requested a review from TheBlueMatt July 9, 2025 22:20

jkczyz added 3 commits August 19, 2025 14:47

Add features for splicing

00b4ade

While splicing is not yet fully supported, checking if the feature has been negotiated is needed for changes to the channel_reestablish logic.

jkczyz force-pushed the 2025-06-channel-reestablish branch from f5c9271 to 719ade4 Compare August 19, 2025 20:37

TheBlueMatt reviewed Aug 20, 2025

View reviewed changes

jkczyz commented Aug 20, 2025

View reviewed changes

jkczyz force-pushed the 2025-06-channel-reestablish branch from 719ade4 to 7c948e4 Compare August 26, 2025 20:14

jkczyz requested a review from TheBlueMatt August 26, 2025 20:16

jkczyz force-pushed the 2025-06-channel-reestablish branch from 7c948e4 to 6850814 Compare August 27, 2025 18:39

jkczyz force-pushed the 2025-06-channel-reestablish branch from 6850814 to 5feb4fd Compare August 27, 2025 20:26

wpaulino reviewed Aug 27, 2025

View reviewed changes

TheBlueMatt reviewed Aug 28, 2025

View reviewed changes

jkczyz and others added 9 commits August 28, 2025 09:22

f - drop irrelevant comment

5365c43

f - use the correct FundingScope

7d77aec

f - request announcement_signatures when splice hasn't been promoted

abe8dae

Retransmit announcement_signatures if requested

6e3c071

The previous commit allowed requesting retransmission of announcement_signatures during channel reestablishment. This commit handles such requests.

jkczyz force-pushed the 2025-06-channel-reestablish branch from 5feb4fd to 6e3c071 Compare August 28, 2025 16:38

wpaulino reviewed Aug 28, 2025

View reviewed changes

Update channel_reestablish for splicing #3886

Are you sure you want to change the base?

Update channel_reestablish for splicing #3886

Uh oh!

Conversation

jkczyz commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 26, 2025

Uh oh!

jkczyz commented Jun 27, 2025

Uh oh!

codecov bot commented Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Jun 28, 2025

Uh oh!

ldk-reviews-bot commented Jun 30, 2025

Uh oh!

ldk-reviews-bot commented Jul 2, 2025

Uh oh!

ldk-reviews-bot commented Jul 5, 2025

Uh oh!

ldk-reviews-bot commented Jul 7, 2025

Uh oh!

jkczyz commented Jul 7, 2025

Uh oh!

wpaulino left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 7, 2025

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkczyz commented Jul 9, 2025

Uh oh!

jkczyz commented Jul 9, 2025

Uh oh!

jkczyz commented Aug 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Update `channel_reestablish` for splicing #3886

Update `channel_reestablish` for splicing #3886

jkczyz commented Jun 24, 2025 •

edited

Loading

ldk-reviews-bot commented Jun 24, 2025 •

edited

Loading

codecov bot commented Jun 27, 2025 •

edited

Loading